Subject: APPN Multicast Services Submission to the AIW

From: "Roy Brabson (254-7332 (T/L 444))" <[email-masked]>
Date: Thu, 6 Oct 94 17:08:03 EDT

Some early comments on the subject document:

It may be preferable to build upon Directory Services for transport of
the multicast GDS variable instead of inventing a new transport
algorithm.  This would be more in keeping with the current APPN
architecture philosophy of having other CP components use DS for
transport of network data.  In addition, it has the following
advantages:

- It will require less code.  There are no new service TPs required for
  the function and no new routing logic required for delivery of the
  data.

- It provides a better level of interoperability.  All APPN NNs support
  the receipt of Locate searches.  The existing directed and broadcast
  search logic can be used to deliver the new multicast GDS variable
  to all NNs in the subnetwork.  Only those which need to understand
  the new GDS variable need to be upgraded in order to parse/process
  it.

  Additional logic will still be required at NNs for search of the ENs
  due to the multicast GDS variable.  This logic will be to both
  include all ENs on a domain broadcast when the multicast search is
  destined for ENs as well as NNs, as well as to omit any EN which has
  requested inclusion on domain broadcasts from the search when the
  multicast GDS variable is destined only for NNs.

- Less new architecture is required.  You don't need to define the new
  spanning tree calculation architecture, nor do you need to define the
  new logic to interpret the spanning tree.  Existing DS algorithms can
  be used to transport the new data.

  In addition, there is no need to add new MCS support characteristics
  to the Node Characteristics CV since a spanning tree does not need to
  be built.

- Unicast will perform better.  Instead of sending a directed Locate
  to find the destination followed by a multicast search, only the
  directed Locate will need to be sent.

- All multicast GDS variable deliveries would be reliable.  Not sure this
  is really a benefit, just a reality given DS always provides reliable
  delivery.

There would be additional logic which would need to be added to DS,
though.  First, there is no concept of a "NETID search" today.  It would
likely be easier for Extended BNs to support changes to DS search logic
for NETID searches instead of providing a new searching mechanism.

A mechanism to enable the search to be restricted to all NNs or all
NNs and ENs would be required.  Currently, there is no "Search All"
function, nor is there a "NN-Only" or "NNs and ENs" indicator.  Both
would need to be added.

Roy Brabson

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 6 Oct 94 19:34:13 EDT

Roy - Thanks for reviewing the spec and sending comments.  Let me see if I can 
address some of your key points.

There's really a very good reason I'm suggesting a new component and not making 
use of APPN DS.   I'd really like to use a new GDS variable and get away from 
locates.  The Locate was specifically designed with the searching function in 
mind and APPN MCS is not necessarily associated with searching.  As you know, 
APPN DS code is actually very complex and I'd like to avoid making a bunch of 
changes to DS code to accomodate this feature.   This feature would require 
implementing a service API to DS which does not currently exist and would end 
up either become a separate logical flow line through DS (in which case it 
might as well be another component) or get really messy in the existing logic.  
If it is a separate component, there's no reason it cannot make use of existing 
routines in APPN DS and any future enhancements or changes to APPN MCS would 
not require getting back into the DS code again and trying to work around in 
it. 

 > the function and no new routing logic required for delivery of the

I'm not sure I agree about the less code statement.  The service TPs are very 
small.  The Send and Receive TPs simply get a message and send it or receive a 
message and pass it to the code that parses it.  If you wanted, you could 
always rewrite the APPN DS TPs to do both functions.  There are always clever 
ways to code.

>  the new GDS variable need to be upgraded in order to parse/process

I don't agree about the better interoperability at all.  Existing APPN nodes 
would freak out if they received a LOCATE without a FIND GDS variable, etc.  So 
the sending node would need to know whether the receiving node supports MCS or 
not (hence CP Caps bits etc).   Assuming the vast majority of MCS messages are 
actually multicasts, I would VERY MUCH like to avoid using APPN DS broadcast 
mechanisms.  We all know this is very bandwidth and CPU intensive and I'd like 
to create a function which is more efficient.  If APPN DS were an efficient 
mechanism for broadcasting messages within a network, then there wouldn't be 
any reason for CDS or Central Resource Registration, or caching, or any of the 
other functions designed specifically to avoid them.  

>  multicast GDS variable is destined only for NNs.

I'm not sure whether this is a comment about my proposal or your proposal.   I 
think it's about your proposal, which only shows how trying to leverage APPN DS 
gets complex.  In my proposal, APPN MCS is either in the NN or it's not.  If 
not, the node doesn't receive an MCS.  If it is, the node will receive the 
MCS.  If an NN receives an MCS, it checks a bit to see if the MCS should go to 
domain ENs.  If so, it gets sent to all ENs supporting MCS, otherwise not.  
Sounds simple to me.

>  be used to transport the new data.

Yes, you don't need new architecture you can use APPN DS broadcast mechanisms 
which are generally beleived to be resource intensive.  I wasn't actually 
proposing to invent any NEW spanning tree architecture.  I was simply proposing 
to use the CPSVCMG spanning tree as known by TRS.  As already mentioned in the 
TRS proposed changes, TRS caches a least cost spanning tree for all active 
COSs... including CPSVCMG.   So the tree is already there and I was hoping to 
make use of it to create a more efficient broadcasting method.   After giving 
the matter some thought, I'm really in favor of the MOSPF like approach where 
each MCS node simply uses it's TRS knowledge of the CPSVCMG tree to identify 
the outbound CP-CP sessions from the local node to nodes in the tree.  Now if 
an MCS is received, it simply forwards the message out on the CP-CP sessions to 
adjacent nodes known to be part of the tree.   To avoid the 'randomization' 
problems in getting all MCS nodes to agree on the same tree, simply always 
choose the lowest CPname when there's  choice.  And then just live with the 
possibility of incomplete broadcasts when a broadcast is sent during a 
transient condition (like a TDU that has not been propagated throughout the 
entire network yet).   I plan to discuss this more at the AIW next week. 

>  to the Node Characteristics CV since a spanning tree does not need to

Agreed.  But I'd rather use the bit than encounter the APPN DS broadcast 
overhead. 

>  directed Locate will need to be sent.

I think I may have not been clear enough in my document.  The directed locate 
is described in the proposal because there might be a request to send a unicast 
to an unknown LU like an EN.  If the CPname specified in the unicast is not 
known to APPN DS (in your proposal) because it is a cross domain EN, APPN DS 
will first send a broadcast to find it.  APPN DS could then send the directed 
locate unicast with the message.  If APPN DS tried to send the broadcast with a 
MCS GDS variable on it (i.e., LOCATE/FIND/MCS), I beleive a whole lot of 
non-MCS APPN nodes would barf due to the presence of the MCS GDS Variable and 
no CDINIT etc.  

>  is really a benefit, just a reality given DS always provides reliable

Agreed.  I see this as a benefit, but after some thought, I'm not sure reliable 
broadcasts are a worthwhile goal as even a reliable multicast will not avoid 
the real problem I was trying to avoid.  I was hoping that a reliable multicast 
would keep applications from sending their multicasts out on a periodic basis 
because they know it already got there.  But unfortunately, a reliable 
broadcast would not solve the problem of when a CP-CP session comes up joining 
two previously unconnected APPN networks.  After this event, there might be a 
whole lot more members in the multicast group, that weren't around on the last 
multicast and the multicast application wouldn't even know this happened.  So 
it would have to periodically multicast for this situation anyway.  I was 
hoping to talk about this some more at the AIW as well. 

>for NETID searches instead of providing a new searching mechanism.

I don't think I agree that it would be easier to change DS in Extended BNs than 
adding the MCS service.  But it's certainly worth discussing.  The one thing I 
really do want to point out is that APPN MCS is not about a "new SEARCHING 
mechanism".    APPN MCS is about a message transport system.  If you need to 
"find" and LU, than I agree... APPN DS is the way to go.

>function, nor is there a "NN-Only" or "NNs and ENs" indicator.  Both

Agreed. And as you and I both know, this isn't very easy.  Hence my proposal 
for a new component which gets out of issues related to accomodating existing 
DS implementations in the field. 

Thanks again for the comments.  Look forward to discussing them with you and 
others at the AIW next week!   Ciao -D

---

From: [email-masked] (Dave Finnie)
Date: Fri, 7 Oct 94 14:59:59 EST

Dave,

This looks like a great idea. I won't be at the upcoming
AIW, so I'll put in my 2 cents worth now:

I agree with you that we should avoid a new feature that
can potentially cause lots of broadcast searchs. As you
rightly pointed out, the architecture goes to great pains to
avoid them at all costs. For this reason, I don't think we
should use the standard search algorithm employed by DS.

I'm not sure that I see a clear advantage either way of
putting the MCS functions into DS or creating a new
CP component. I don't think it would overly complicate
DS, nor would bucket loads of code be saved. If I did
have to chose, however, I would go for a separate
component - simply because what might be a simple 
function today might end up growing further down the
track, and that would then start making DS more
complex.

What I wouldn't mind seeing added is an ability
for newly connected nodes/MCS applications to inform
the rest of the network that they have just connected.
This would avoid (reduce) applications needing to
re-send MCS messages "just incase" a new node has 
entered. Once an MCS application has joined a group,
origin MCS applications could then decide if the
new application should be updated with old messages.

To this end, perhaps a standard multicast_address
should be defined that is an implicit part of MCS
processing. When an MCS application "joins" a
multicast group, an MCS message is sent (using the
standard multicast_address) that indicates that the
node in question is now part of the joined group.

Whadayathink ?

Dave

---

From: "Roy Brabson (254-7332 (T/L 444))" <[email-masked]>
Date: Fri, 7 Oct 94 09:31:50 EDT

Dave, my comments are interspersed below.  See you next week to discuss
the proposal.

> not require getting back into the DS code again and trying to work around in

I did see MCS as a separate component.  I just saw it as a component
which used DS for transport.  The actual changes to DS to transport a
new GDS variable instead of a Cdinit is really not much.  And DS already
supports multiple components requesting a search and/or delivery of a
GDS variable, so adding a new interface should be real cheap.

I'm not sure I see why this would be a separate logical flow through DS.
It seems that most of the logic would remain unaltered.  DS serves two
main functions, searching and the transport of DS and non-DS data.  MCS
would simply use DS for searching (in the case of unicast) and data
transport (for both cases).

> always rewrite the APPN DS TPs to do both functions.  There are always clever

True, the service TPs are rather small.  But you will need to devise a
new interface to TRS to request a spanning tree, create new logic for
sending directed and broadcast searches (the broadcast uses the spanning
tree), etc.  This is all new.  DS already has proven logic for sending
both a directed and a broadcast search.  Seems it would be cheaper to
reuse this instead of invent a new one.

> other functions designed specifically to avoid them.

You would obviously need to send a Locate-Find-MCS search each time.  The
only trick is, for the MCS multicast, you would need to ensure the search
reached all nodes.  But this really shouldn't be too difficult.

As to bandwidth consumption, I'm not sure how much will be saved.  I
guess the questions which would need to be answered are:

o How many NNs are there in the network, and how many CP-CP sessions
  between them?  The spanning tree concept will require the MCS searches
  to carry the additional data of the spanning tree, and it will need
  to be complete for at least the first hop even if a stripping algorithm
  is generated.

  In either case, once all nodes in the network support MCS, all NNs
  must receive the search and, potentially, all ENs as well.  The tradoff
  would be the extra bandwidth used to send the spanning tree vs. the
  extra bandwidth of having a single extra DS search sent between each
  pair of adjacent NNs.

o How often is the MCS component going to perform multicasts?  If it is
  quite often, then by all means it should be designed for optimal
  performance.  But my guess is it will be used quite rarely, in the
  greater scheme of APPN CP functions.  As such, the design point should
  be towards a simpler function.  And, if unicast is being used more
  than multicast, the use of DS will provide better performance and less
  bandwidth/CPU consumption.

> domain ENs.  If so, it gets sent to all ENs supporting MCS, otherwise not.

This was more of a comment on the use of DS for transport.  Since the
goal will be to have all NNs and ENs support MCS, in time the delivery
will be to all NNs and ENs.  I was simply commenting that, if DS is used
for transport, then an NN would need to support MCS in order to deliver
the data to ENs which also support MCS.

> entire network yet).   I plan to discuss this more at the AIW next week.

An MCS multicast is going to be a rather CPU intensive procedure in its
own right.  Anytime you require delivery to all nodes in the network
(assuming all nodes support MCS, which really must be the case if MCS is
to be of much use), you are going to consume lots of bandwidth and CPU
time.  DS does this using a flooding algorithm, where each CP-CP session
is traversed twice (once for the request, once for the reply).  The
number of messages sent is 2*S, where S is the number of CP-CP sessions.
MCS, on the other hand, uses a CP spanning tree algorithm where each
node receives at most one messages and, in the case of reliable delivery,
sends a reply as well.  For reliable delivery, the cost is 2*N, where N
is the number of nodes.

For ENs, the algorithm doesn't matter - they have at most one CP-CP
session so they will receive at most one message either way.  For NNs,
it really depends on how the network is designed.  You will see more
messages sent, but it isn't an order of magnitude higher.

I'm also concerned that MCS may not provide reliable delivery, even when
it is requested.  Transient conditions in an APPN network often take some
time to settle down.  If the origin truely required delivery of data to
all MCS-capable nodes, retry logic would need to be devised.  DS
broadcast logic, on the other hand, will work even in the presence of
these "transient" conditions.

> non-MCS APPN nodes would barf due to the presence of the MCS GDS Variable and

Maybe, and if so a good enough point to kill the use of DS broadcast for
delivery.  All products support receiving a Locate-Find without a Cdinit
(used for MS), and should treat any other GDS variables as unknowns.  It
*should* work, but should doesn't always match reality.

> "find" and LU, than I agree... APPN DS is the way to go.

Just speaking from experience.  DS logic at an EBN would be easy to
modify.  New MCS transport logic is just that, new.

> DS implementations in the field.

To be honest, I'd love to find a way to do a "Search All" function in
DS.  Either placing the origin CP's name in the Find or placing a new,
reserved LU name in the Find, are two possibilities.  Don't know how
products would react to the first, but the second would definitely
guarantee delivery to all NNs at least and, if the NNs support MCS, to
all ENs as well.  Just food for thought.

Roy

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 7 Oct 94 9:17:11 EDT

Dave - Sorry to hear you won't be there.  Yes, one of the reasons I advocate a 
new component is because of anticipated future enhancements.   I think the 
component my eventually becomes somewhat sophisticated in it's own right.  

With regard your suggestion about using a multicast address group to track 
group joins and leaves, my thinking was that this kind of thing would be the 
function of the applications riding above the MCS service.  It may be that many 
MCS applications won't  need to know about messages sent before they joined the 
group.  So it's better to leave that up to the application.  This way we keep 
MCS simpler, easier to implement, and therefore more widely implemented (and 
available) in customer networks.  

An interesting compromise would be to add a new MCS API signal that notifies 
requesting applications of new CPs entering the network.  This way the MCS 
application can do whatever it has thinks is right for the situation.   
Implementation would simply be a signal sent from TRS to MCS and then up to 
applications requesting this notification.   The API would have 2 new signals,
one requesting notification of new CPs, with an on/off parameter, the other 
would be an indication signal from MCS to the application when the event is 
detected in TRS.

Thanks for the comments!

Dave Bryant
3Com Corp     

----- Previous Message ---------------------------------------------------- 

To: aiw-appn-reference  @ networking.cary.ibm.com @ UGATE
cc:  
From: dave @ insession.com (Dave Finnie) @ UGATE    
Date: Friday  October 7, 1994 02:59 PM
Subject: Re: APPN Multicast Services Submission to the AIW
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Dave,

Whadayathink ?

Dave